Short version. We're spending two days building the layer that lets anyone at Cornell get a governed, running piece of AI infrastructure by asking for it in plain language — and learning AWS's AI-DLC methodology by doing it for real rather than in an exercise. This brief replaces the one you got with your invitation; §7 notes what changed.
1The long-term vision
AI-SEI runs Cornell's central AI Platform. What we're missing is the layer between that platform and you: a catalog of reusable, governed building blocks that any unit can compose into a working application, without needing to become cloud engineers and without us hand-building it for them.
The way it should feel: an instructor — not an engineer — says "I want a chatbot my students can ask questions about my course material," and something works out what that needs and stands it up.
Three blocks get selected: internal audience → a Teams bot; needs the course material → a document pipeline; needs somewhere to retrieve from → a database. They're deployed together, into AWS accounts we manage, with our guardrails around them. The builder never touches the cloud — the whole point is that it's abstracted away.
Where this goes: eventually all custom development at Cornell targets this platform and this methodology. Not just AI features and not just agents — everything from a full-stack web application down to a two-step workflow automation, built as a composition of governed blueprints, developed with AI-DLC, deployed through one pipeline, and visible in one inventory.
That means the catalog has to grow well past AI-shaped things: SSO-protected dashboards and web apps, API layers in front of systems of record, scheduled and event-driven jobs, batch data processing, UI hosting. Today, a unit that needs any of those builds it however it likes, wherever it likes, and we often find out later. The end state is one sanctioned path that's faster than the alternative — which is the only reason anyone ever takes a sanctioned path.
Why you're in the room. This is meant to be a shared, contributable platform, not something one team owns and everyone else queues for. "Your platform doesn't let me do X" should start a contribution that improves it for every unit. You're here because that only works if the people who'd actually use it help design it — and because AI-DLC is deliberately not a developers-only method.
2What we're building in the two days
The vision above is months of work — that's the bet AI-DLC makes, and this workshop is how we test it. Here's the slice we think is achievable in roughly six hours of build time, organised as six tracks. You don't need to pick now — we'll sort teams Monday morning with the AWS facilitators, and several places are deliberately left open.
| 0 | The deploy path
GitHub → CodePipeline → CodeBuild → CloudFormation, working and debuggable, so no other track loses an hour to a red pipeline. Terraform for the Microsoft 365 pieces.
Marty Sullivan, Dan Klinger, with Mike Brugnoni (AWS) |
| A | The "Cornell Builder" — the keystone
The thing in the diagram. A tool in your Claude Cowork or Claude Code that searches available blueprints, creates a repo from a template, and kicks off a deployment. Includes the review gate: you open a pull request, it's reviewed, and merge deploys. (Long term that reviewer is an automated agent; this week it's a person.)
Ayham Boucher, Jai Chandnani, Zain Kahn, Tim Fraser |
| B | Documents → searchable knowledge
Take a pile of documents and make them retrievable by an application — using a managed Amazon Bedrock Knowledge Base to handle the extraction, chunking, and indexing. The classic "we have a folder of PDFs, make them useful" job, with the effort going into ingestion quality and retrieval tuning rather than plumbing.
Steve Mandl, Ido Efrati, Axel Stevens |
| C | A Microsoft Teams chatbot
Internal chatbots at Cornell should front on Teams. Azure Bot Framework on the Microsoft side, everything behind it running on AWS. Success is someone in the room messaging it and getting a real answer.
Scott Ross, Jason Woodward, Andre Hafner |
| D | How the blocks talk to each other, and stay separated
Our hardest open question. If a deployment is three blocks, what do they use to communicate — and how do we guarantee one unit's deployment can't reach another's? Deliverable is a decision with the trade-offs written down, plus a working example.
Philip Williammee, Tom Davko |
| E | Seeing what's running
A dashboard: centrally, every deployment across the university with its owner and health; for a unit, only their own — metrics, logs, failures, cost — without giving them access to our AWS account.
Jasdev Imani, Christopher Cameron, Franklin Castle |
Chris Garlington, Pete Caforio, Pete Stergion, Dennis Nardi and Sean Gnau are unassigned on purpose — we'll place you Monday where the room needs you.
3What success looks like at 2:00 PM Tuesday
One sentence: someone asks for something in plain language, and the room watches it become a governed, running, observable deployment. The Tuesday audience is provost-level, and the question in that room is whether Cornell should build things like this or buy them. Slides won't answer it. A working chain will.
Concretely, the seven beats every track is working toward:
- A Cornell instructor types into Claude Cowork: "I want a chatbot my students can ask questions about my course material."
- The Cornell Builder comes back with matching blueprints and one gets picked. (A)
- A new repo appears in our GitHub org from the template — shown live. (A + 0)
- Claude Code writes the customization and opens a pull request — no one gets direct write access, and review-then-merge is the governance gate. In the target state that reviewer is an automated agent. (A)
- The pipeline runs — CodePipeline → CodeBuild → CloudFormation — live, going green. (0)
- Someone opens Teams, messages the bot, and it answers from the actual course documents. (B + C)
- The dashboard shows the deployment that just appeared, with its owner and estimated cost. (E)
The plan is to show the governance loop live (beats 1–5) and then message a bot deployed earlier that same morning — two instances rather than one. If everything rehearses green, we upgrade to running all seven beats as a single continuous chain. Either way we're demonstrating software, not presenting diagrams — which is why the scope above is smaller than our ambition.
One honest simplification: in the diagram in §1, the Builder composes multiple blocks into one deployment. This week each request deploys one blueprint — the course-chatbot template bundles the Teams frontend, document pipeline, and database together. Composition of separate blocks is the very next thing on the roadmap; tracks B–D exist to make those seams real.
4The agenda
| Mon 9:00–10:00 | Introduction and kick-off. Teams get formed here. |
|---|---|
| Mon 10:00–12:00 | Inception — intent into user stories, user stories into Units of Work. This is Mob Elaboration, and it's the part where non-developers matter most. |
| Mon 12:00–1:30 | Lunch, likely a working one. |
| Mon 1:30–4:00 | Construction — component model design, then code generation. |
| Mon 4:00–5:00 | Day 1 retrospective — also where we honestly re-cut scope if something isn't moving. |
| Tue 9:00–9:30 | Day 2 kick-off. |
| Tue 9:30–2:00 | Construction continues, working lunch. The most productive block of the event. |
| Tue 2:00–4:00 | Demo and reflections. §3 is what we're demoing. |
| Tue 4:00–5:00 | Wrap-up, possibly some deployment work. |
5Drivers and everyone else
Roughly two-thirds of the room will be at a keyboard with Claude Code open. The rest are not spectating — AI-DLC is explicitly not a developers-only method, and a few of the roles below are genuinely load-bearing:
| Driving | Running Claude Code, writing and reviewing what it produces, deploying. If that's you, §6 is mandatory. |
|---|---|
| Program management Sylvie Honig, Andrea Frank, Erica Ellis | Capturing the AI-DLC artifacts — requirements, Units of Work, design decisions — that let us keep going after AWS leaves. Without this the workshop evaporates on Wednesday. |
| Service management & operations Alysia Villanti, Sean Walsh | The path from "this works" to "this is a supported service": intake, TDX, and what it takes to run a fleet of these once units start shipping. |
| Requirements & demand Zach Jacques, Fermin Romero, Ernie Francis | Leading the discussion from the consuming side. You run teams and units with real backlogs — you're the ones who can say whether a blueprint is worth adopting and what's missing from the catalog. |
| Everyone | Inception, Monday 10:00–12:00, is a whole-room activity. The quality of the two days depends more on that block than on anyone's typing speed. |
6Prerequisites — a reminder
We've already sent the prerequisites separately; this is just the summary so it's in one place with everything else.
- GitHub username — if you expect to drive. Everything we build deploys through GitHub, and access has to be granted ahead of time. If you don't plan to drive, you don't need one.
- Claude Code installed and working, with your AI Gateway API key configured.
- Your laptop and a charger either way. Room 250 has limited outlets.
- Optional but useful: come with one thing your unit would want from the catalog in §1 — not to solve this week, but as input to Inception.
You will not need an AWS account or console access. That's deliberate: the builder experience we're designing doesn't include one, so we're rehearsing the real thing. Kick-off runs 9:00–10:00 and Inception starts at 10:00, so arriving with working tooling means you don't miss any of it.
7What changed since your invitation
The brief you received listed six candidate blueprints, including event-driven automations and UI automation of legacy desktop applications via Amazon WorkSpaces. Both are real parts of the long-term vision and neither is in scope for these two days — with six hours of build time we'd rather finish a narrow chain end to end than start six things. If one of those was why you said yes, please tell us; they're near the front of the queue for what comes next, and there's a broader workshop planned once this MVP is done.